home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19941221-19950208
/
000071_news@columbia.edu_Mon Jan 2 17:36:32 1995.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
5KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04717
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 2 Jan 1995 12:36:34 -0500
Received: by apakabar.cc.columbia.edu id AA18952
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 2 Jan 1995 12:36:33 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: File transfers are too slow
Date: 2 Jan 1995 17:36:32 GMT
Organization: Columbia University
Lines: 77
Message-Id: <3e9dj0$ig6@apakabar.cc.columbia.edu>
References: <3e51i2$jka@csusac.ecs.csus.edu>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3e51i2$jka@csusac.ecs.csus.edu>,
Jon M. Taylor <taylorj@ecs.ecs.csus.edu> wrote:
>Situation: I am connecting from my home computer (486/33,
>v.32bis modem, latest beta DOS kermit 3.14) to the university computer
>(HP 9000/715, OS 9.x) Via a Xyplex terminal server ...
> Anyway, I have compiled 5A(190) for HPUX, and it seems to work
>correctly (so far, anyway). I get maximal throughput with packet length
>set to 2000 (more works OK, but doesn't seem to make a difference in
>throughtput), all the control characters from the FAST macro enabled, and
>windows set to 1. My modem DTR is locked at 38400, compression and error
>correction enabled, and it connects to the Xyplex at 14.4k with
>compression and EC on. With this setup, I get ~1150 CPS.
> Here's the rub: Things start breaking down with any other window
>setting than 1.
>...
>- c-kermit on the HP initially uses XON/XOFF. I'm not sure whether to
>change this or not - would the Xyplex need it? I *think* the xyplex uses
>XON/XOFF to talk to the HP and DSR/DTR to talk to my modem....
>
Like it says in the documentation... tell C-Kermit on the host to
"set flow none". It has a TCP/IP connection (TELNET or RLOGIN) to the
terminal server, and the network protocol itself provides the flow control.
Disabling Xon/Xoff in this situation should perk things up quite a bit.
Second, make sure you have RTS/CTS enabled in MS-DOS Kermit on your PC
*and* on your modem. Most of our high-speed dialing scripts take care
of this automatically.
I don't know a huge amount about Annexes, but I'll speculate that you
are uploading. Many kinds of terminal servers were designed to have
big buffers in the host-to-terminal direction and small ones in the
opposite direction. This is bad for uploading files. At the very least,
the system/network administrators must ensure an extremely effective
and responsive method of flow control between the terminal server and the
answering modem (preferably RTS/CTS). Better still, perhaps they can
reconfigure the terminal servers to allocate buffer space more equitably.
Or maybe the Annex has some kind of command that you can give at its
prompt that will condition it for file transfers, similar to the Cisco
terminal server's "terminal download" command.
Finally, about the window size -- please read in the documentation about
sliding windows. The file receiver will never use a window size greater
than 1, even if a larger size has been SET and successfully negotiated,
unless packets are lost or damaged. That's because normally packets
arrive in their correct order and therefore each one is disposed of
promptly as it arrives.
> Also, while I'm here, I want to say thanks to Joe Doupnik (I used
>to go to school at USU!) and Frank da Cruz for MS-Kermit and C-Kermit.
>NOTHING but Kermit will work over this damn Xyplex, and I'm really glad
>it's out there.
>
Thanks.
>A couple suggestions: Have the percentage efficiency and
>CPS rating be updated in realtime during the transfer, like most other
>common protocols do.
>
C-Kermit does this (when you use SET FILE DISPLAY FULLSCREEN), but
generally speaking, size and efficiency are a bigger issue for MS-DOS
Kermit, which must still run on 4.77MHz 8088s. Maybe some day this could
be added as an option, but not in version 3.14.
>Also, since you seem to be aiming for maximum configurablility,
>how about an option to completely turn off ALL error checking in the
>protocol (like Ymodem-G)? It would add another little speed boost to
>those who have EC modems.
>
As Joe says, and has been explained repeatedly on many newsgroups,
most recently on comp.dcom.modems, this would be a false economy. Even
if modem connections could be regarded as 100% reliable and error-free,
there are end-to-end issues of flow and error control, not to mention
presentation issues, etc, that are beyond the modems' sphere of
influence.
- Frank